REMARKS 



Claims 47-57 have been amended. Claims 1-11 and 23-57 remain pending in the 
application. Reconsideration is respectfully requested in light of the following remarks. 

Section 101 Rejection : 

In the Action dated November 1, 2007, the Examiner rejected claims 47-57 under 
35 U.S.C. § 101 because the claims are not directed to statutory subject matter. The 
Examiner states "according to Applicant's disclosure, page 39 lines 13-20, the computer- 
accessible storage medium is not limited [to] storage medium, instead it is defined to 
include both storage medium... and transmission medium." Page 39, lines 15-20 state 
(emphasis added): 

Generally speaking, a carrier medium may include storage media or 
memory media such as magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM (e.g. SDRAM, DDR 
SDRAM, RDRAM, SRAM, etc.), ROM, etc. AS WELL AS transmission 
media or signals such as electrical, electromagnetic, or digital signals, 
conveyed via a communication medium such as network and/or a wireless 
link. 

Note that claims 47-57 have been amended to recite a computer-readable storage 
medium storing program instruction , and do not recite just a "medium" or a "carrier 
medium." Storage media are clearly described in the specification as encompassing 
tangible, physical articles or objects, ("magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM, ROM, etc,"), and thus storage media are 
statutory subject matter. Storage media are clearly differentiated in the specification 
from "transmission media or signals such as electrical, electromagnetic, or digital 
signals." 

In the Response to Arguments section of the Action dated April 17, 2008, the 
Examiner maintains the § 101 rejection of claims 47-57. Applicant respectfully 
maintains the traversal of the Examiner's rejection. However, in order to expedite 
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prosecution, Applicant has amended claims 47-57 in this response to recite "computer- 
readable storage medium" rather than "computer- accessible storage medium". 

Applicant quotes again from page 39, lines 9-12 of the specification (emphasis 

added): 

Generally speaking, a carrier medium may include storage media or 
memory media . . . AS WELL AS transmission media or signals. . . 

The quoted portion of the specification clearly differentiates between storage 
media or memory media and transmission media. In addition, page 10, line 24 - page 11, 
line 1 states: 

Memory 204 is representative of various types of possible memory media , 
also referred to as " computer readable media ." Hard disk storage, floppy 
disk storage, removable disk storage, flash memory and random access 
memory (RAM) are examples of memory media. The terms "memory" 
and "memory medium" may include an installation medium, e.g., a CD- 
ROM or floppy disk, a computer system memory such as DRAM, SRAM, 
EDO RAM, SDRAM, DDR SDRAM, Rambus RAM, etc., or a non- 
volatile memory such as a magnetic media, e.g., a hard drive or optical 
storage. 

This citation from the reference further makes clear that the phrase "computer- 
readable storage medium" in the amended claims recites statutory subject matter. 
Storage media are clearly described in the specification as encompassing tangible, 
physical articles or objects, (e.g., "magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM... ROM, etc,"), and thus storage media are 
statutory subject matter. 

Again, in addition to the above arguments, Applicant refers the Examiner to 
Decision on Appeal 2007-2225 in the case of U.S. Patent Application 10/054,809, 
decided August 31, 2007. In the case, a similar § 101 rejection of claims that recite a 
"computer-accessible storage medium" was appealed. The specification of U.S. 
Patent Application 10/054,809 includes the same verbiage as quoted above from 
page 39, lines 15-20 of the specification of the instant application. The Decision on 
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Appeal reversed the § 101 rejection in that case. That Decision on Appeal is directly 
on point in this case . 

Thus, Applicant respectfully maintains the request for removal of the § 101 
rejection of claims 47-57. 

Section 112, Second Paragraph, Rejection : 

The Examiner rejected claims 1-11 under 35 U.S.C. § 112, second paragraph as 
indefinite in the use of the term "configured to." The Examiner's rejection is improper in 
that it ignores functional limitations. The Examiner asserts that the use of "configured 
to" in the claims recites an intended use and has no patentable weight. However, the 
"configured to" limitations in Applicant's claims are functional limitations. The various 
instances of "configured to" in the claims accompany language that recites specific 
limitations of the corresponding element. In other words, the claims describe how the 
claim elements arc actually configured to function , not merely an intended use. The use 
of functional limitations to define an invention has been expressly approved by the 
courts. See, e.g., In re Swinehart, 439 F.2d 210, 169 USPQ 226 (CCPA 1971). In fact, 
the Court has held that a functional claim limitation is proper and can distinguish over the 
prior art "because it set definite boundaries on the patent protection sought." In re Barr, 
444 F.2d 588, 170 USPQ 33 (CCPA 1971). Moreover, the Court has held that limitations 
using "configured to" or "adapted to" serve to precisely define present structural 
attributes of interrelated component parts of the claimed assembly. In re Venezia, 530 
F.2d 956, 189 USPQ 149 (CCPA 1976). Applicant also refers the Examiner to the claim 
construction using "configured to" limitations in State Street Bank & Trust Co. v. 
Signature Financial Group Inc., 47 USPQ2d 1596 (Fed. Cir. 1998). 

If the prior art computer did not store executable instructions or include other 
structure capable of performing the exact functional limitations recited in Applicant's 
claim, then the prior art computer would not teach a computer configured to implement 
the same invention. The functional limitations of Applicant's claim recite positive and 
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definite capability requirements that are simply not meet by the teachings of the cited art. 



Thus, Applicant respectfully requests removal of the § 112 rejection of claims 1- 

12. 

Section 103(a) Rejections : 

The Examiner rejected claims 1, 2, 3, 5-1 1 and 23-57 under 35 U.S.C. § 103(a) as 
being unpatentable over Lev Ran et al. (U.S. Patent 7,139,81 1) (hereinafter "Lev Ran") in 
view of Kunisetty (U.S. Publication 2003/01721 10) and further in view of Karakashian et 
al. (U.S. Publication 2007/0150546) (hereinafter "Karakashian"). Applicant respectfully 
traverses this rejection for at least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, the cited art fails to 
teach or suggest a remote procedure call system comprising a presentation block 
configured to present data types and Application Programming Interfaces (APIs) 
available to a program on the system. 

In the Action dated April 17, 2008, the Examiner relies on Lev Ran, and cites Lev 
Ran, "RPC request messages," col. 56, lines 19-25, "java object... object class or type," 
col. 58, lines 40-67, col. 59, line 64 - col. 60, line 46, and "empty RPC request object," 
col. 62, lines 5-16 in support of the assertion that Lev Ran teaches a presentation block 
configured to present data types to a program on the system. In point (2) of the Response 
to arguments, the Examiner provides an explanation for the Examiner's reliance on the 
above citations from Lev Ran, asserting "the object types are attributes of a piece of data 
that tells the computer (and the programmer) something about what kind of data is being 
dealt with and therefore meeting the claimed limitation of a presentation block that 
presents data types." Applicant respectfully traverses the Examiner's assertions for at 
least the reasons given below. 
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The Examiner cites Lev Ran, col. 56, lines 19-25, and appears to assert that "RPC 

request messages" are equivalent to "[presenting] data types." The cited reference does 

not teach or suggest that RPC request messages are used to present data types available 

to a program on the system. The Examiner also cites Lev Ran, col. 58, lines 40-67, and 

states "java object... object class or type". It appears to the Applicant that the Examiner 

is equating "java object. . .object class or type" to "data types". Applicant notes that col. 

58, lines 40-67 is from a section of the Lev Ran reference titled "Encapsulation", a 

section describing the data encapsulation layer 164, which performs 

serialization/deserialization. Col 58, lines 53-54 state that: 

Each object class, or type , preferably has its own serializer and 
deserializer. 

Applicant fails to see how this citation has anything to do with presenting 
data types available to a program on a system. Lev Ran does not teach or suggest in 
the citations that Lev Ran's system, e.g. the application transport layer 46, presents 
"java object... object class or type" to a program on the system. 

In the Action dated May 15, 2007, in response to the above arguments, the 

Examiner asserts "As for a remote procedure call system comprising a presentation 

block configured to present data type to a program, page 12 describes the presentation 

block as follows, 'Presentation 100 encompasses the data types that may be passed 

between remote systems...'. The 'java object/object class or type' passed in an RPC 

request/response as disclosed on column 56 lines 20-25 and column 58 lines 40-67 of the 

Lev Ran prior art is the data type passed between remote systems as the instant 

specification discloses." However, col. 56, lines 20-25 does not teach or suggest that 

RPC request and RPC response messages are used to present data types available to a 

program on the system . The full paragraph that includes this citation reads as follows: 

Remote services are activated by bidirectionally transferring remote 
procedure call (RPC) messages between a client application transport 
layer ("RPC client") on one VFN gateway and a server application 
transport layer ("RPC server") on a second remote VFN gateway. 
Preferably, the application transport layer functions asymmetrically, 
whereby the RPC client sends RPC request messages to the RPC server, 
and the RPC server responds by sending RPC response messages to the 
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RPC client . RPC request messages include the request and any necessary 
parameters, and RPC response messages include any necessary return 
values, such as a file. RPC requests, RPC responses, parameters, and 
return values are preferably Java objects, in order to support Java-based 
implementations of the higher application layers. Alternatively, the 
application transport layer functions symmetrically, whereby in addition to 
the RPC client issuing requests to the RPC server, the RPC server can 
issue requests to the RPC client. In such a symmetric implementation, the 
RPC server can connect to the RPC client at a later time in order to 
respond to an earlier request from the RPC client. 

The purpose of the RPC messages as taught by Lev Ran is to "activate remote 
services." In Lev Ran, an RPC client on one VFN gateway and an RPC server on anther 
remote VFN gateway exchange RPC messages to "activate a remote service". Lev Ran 
simply discloses that "RPC requests, RPC responses, parameters, and return values are 
preferably Java objects, in order to support Java-based implementations of the higher 
application layers." The citation does not teach or suggest anything like the notion of a 
presentation block configured to present data types [and Application Programming 
Interfaces (APIs) available] to a program on the system . The presentation block as is 
recited in claim 1 has nothing directly to do with the exchange of RPC messages between 
a client system and a remote server. Indeed, in claim 1, it is clearly recited that the 
sending of messages to a "remote system" is handled by the transport block of the remote 
procedure call system, and not by the presentation block of the remote procedure call 
system. The presentation block is instead configured to present "data types and APIs" 
available to a program on the system . Furthermore, the "program on the system" in claim 
1 is clearly and distinctly a different entity than the "remote system" to which "encoded 
and protocol framed outgoing messages" are moved over an interconnect by the transport 
block . 

As to Lev Ran, col. 58 lines 40-67, Applicant again notes that col. 58, lines 40-67 
is from a section of the Lev Ran reference titled "Encapsulation", a section describing the 
data encapsulation layer 164 , which performs serialization/deserialization. (Applicant 
notes that this selection is not describing Lev Ran's application transport layer 46, but is 
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instead describing a different component of Lev Ran's system.) In this citation, Lev Ran 
discloses that: 

As mentioned above, RPC parameters are preferably Java objects. Before 
a Java object can be sent to a remote application, it must be converted to 
an XML or binary representation. This conversion is commonly referred 
to as serialization, or "encoding." The XML or binary representation is 
passed to the remote application, which converts it back to the original 
Java object. This conversion back is commonly referred to as 
deserialization, or "decoding." RPC client 170 and RPC server 168 use 
serializers to perform encoding, and deserializers to perform decoding. 
Preferably, serializers and deserializers are Java objects that implement 
appropriate Java interfaces, as described below. 

Each object class, or type , preferably has its own serializer and 
deserializer. Data encapsulation layer 164 provides several generic 
serializers and deserializers for common object types, such as String, 
Integer, Float, Boolean, and byte[]. 

Applicant fails to see how this citation dealing with serialization/deserialization 
has anything to do with presenting data types and Application Programming Interfaces 
(APIs) available to a program on a system, as is recited in claim 1 . Lev Ran clearly does 
not teach or suggest that the data encapsulation layer 164 (or the application transport 
layer 46) presents "java object... object class or type" to a program on the system . Lev 
Ran instead teaches, in the first citation, that the application transport layer 46 on a client 
system and the application transport layer 46 on a remote server exchange RPC messages 
"to activate remote services", and that "preferably" Java objects are used in the message 
exchange "in order to support Java-based implementations of the higher application 
layers." The second citation, when discussing the data encapsulation layer 164 , simply 
describes the serialization/deserialization of "common object types". These citations do 
not teach or suggest anything like a presentation block configured to present data types 
[and Application Programming Interfaces (APIs) available] to a program on the system, 
as is recited in claim 1 . 

The Examiner also cites Lev Ran, col. 59, line 64 - col. 60, line 46, which 
encompasses Lev Ran's "Listing 5" and "Listing 6". This citation (col. 59, line 64 - 
col. 60, line 46), like the other citations, does not teach or suggest anything like a 
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presentation block configured to present data types [and Application Programming 
Interfaces (APIs) available] to a program on the system, as is recited in claim 1. Col. 
59, lines 54-56 describe Listing 5 (emphasis added): "A preferred Java interface of a 
binary deserializer is shown in Listing 5. Serializers for decoding binary parameters to 
Java objects implement this interface." Listing 5 is clearly directed at Lev Ran's data 
encapsulation layer 164 . Col. 60, lines 13-14 describe Listing 6 (emphasis added): A 
preferred structure of an RPC message using MIME Multipart/Related is shown in 
Listing 6." Listing 6 simply describes a "preferred structure" of an RPC message in Lev 
Ran's system. Neither citation teaches anything like the limitations as recited in claim 1 
when considered as a whole. 

The Examiner also cites Lev Ran, col. 62, lines 5-16, and quotes from that 
selection ". . .empty RPC request object. . .". It appears to the Applicant that the Examiner 
may be equating "empty RPC request object" to "data types". This citation is from a 
description of FIG. 14, which Lev Ran describes as "a method for processing an RPC 
request by [an] RPC client" (col. 62, lines 5-6). Note that the snipped quote from the 
section comes from a sentence reading in part "The RPC client requests an empty RPC 
request object..." Applicant fails to see how this citation, in which an RPC client is 
described as requesting an empty RPC request object, has anything to do with presenting 
data types available to a program on a system. 

In the Action dated April 17, 2008, the Examiner cites Lev Ran, 'Adaptation 
Layer 45", col. 48, line 65 - col. 49, line 3, col. 49 lines 38-67, and col. 52, lines 6-10 in 
support of the assertion that Lev Ran teaches a presentation block configured to 
present... Application Programming Interfaces (APIs) available to a program on the 
system. In point (2) of the Response to arguments, the Examiner provides an explanation 
for the Examiner's reliance on the above citations from Lev Ran, asserting "Lev Ran 
discloses an adaption layer. ..that provides a transmitter and receiver application layers 
(RPC client/RPC server/application layer) with high level services for bidirectional 
gateway communications over a wide area network using by allowing the adaptation 
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layer of the transmitter application layer [to] communicate with the adaptation layer of 
the receiver application layer." 

Col. 48, line 65 - col. 49, line 3 states (emphasis added): 

Adaptation layer 45 (FIGS. 3 and 4) provides the VFN transmitter and 
receiver application layers with high-level services for bidirectional inter- 
VFN gateway communications over the WAN. As shown in FIG. 4, the 
adaptation layer of a VFN transmitter communicates with the adaptation 
layer of a VFN receiver of another VFN gateway . 

Adaptation layer(s) 45, are components of VFN transmitter 52 and VFN receiver 
48, which are components of VFN gateways 22, which are in turn instantiated on VFN 
systems 20, which are clearly distinct from other clients and servers in Lev Ran's system 
(see, for example, FIGs 1 through 3). The Lev Ran reference describes a Virtual File- 
Sharing Network (VFN) that enables client computers on one LAN to access files held by 
file servers on other LANs. The VFN comprises two or more VFN gateways , each of 
which is connected to a different LAN . The VFN gateways communicate with one 
another over the interconnection provided by the WAN. In order to serve a resource from 
a file server on a first LAN to a client on a second LAN, the VFN gateway on the first 
LAN fetches the resource from the file server and transmits the resource over the WAN 
to the VFN gateway on the second LAN, which then serves the resource to the client. In 
contrast, the remote procedure call system recited in claim 1 of the instant application is 
described as being implemented in memory on a system, and the presentation block is 
described as exposing APIs and data types to a program on the system . The remote 
procedure call system is configured to, on behalf of the program on the system , encode 
representations of the data types, frame the encodings, and transport the messages from 
the system to a remote system over an interconnect. Again, in contrast to Lev Ran's 
Adaptation layer, which "provides the VFN transmitter and receiver application layers 
with high-level services for bidirectional inter- VFN gateway communications over the 
WAN," the presentation block of applicant's claim 1 is configured to present [data types 
and] Application Programming Interfaces (APIs) available to a program on the system . 
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In the Action dated May 15, 2007, the Examiner asserts "it is noted that the 
features upon which applicant relies (i.e., a presentation block configured to present data 
type and application programming interfaces to a separate and distinct program) are not 
recited in the rejected claim(s). . .A presentation block configured to present data type and 
application programming interfaces to a separate and distinct program has not been 
claimed and as such was not considered." The Examiner is incorrect. Applicant notes 
that the Examiner should consider the claim as a whole. Claim 1 recites a system 
comprising a processor and a memory comprising program instructions executable by the 
processor to implement a remote procedure call system . The remote procedure call 
system as recited in claim 1 comprises a presentation block , an encoding block , a 
protocol block , and a transport block . The presentation block is configured to present 
data types and Application Programming Interfaces (APIs) available to a program on the 
system . A plain reading of the entirety of claim 1 makes it clear that "a program on the 
system" is something other than the remote procedure call system itself , and is not 
included in the remote procedure call system, nor is it implemented by the program 
instructions that implement the remote procedure call system, and thus is not comprised 
in or by the remote procedure call system. Applicant's reference to "a separate and 
distinct [from the remote procedure call system] program on the system on which the 
remote procedure call system is implemented" does not require limitations from the 
specification to be read into the claim, as the Examiner wrongly asserts. Instead, 
Applicant is simply arguing the plain meaning of the claims. By stating that the remote 
procedure call system presents data types and APIs to a program on the system , the plain 
meaning of the claim is clear that the program is separate and distinct from the remote 
procedure call system itself If one thing presents something to another thing, then 
they are clearly two separate and distinct things. Again, neither Lev Ran's data 
encapsulation layer 164 nor Lev Ran's adaptation layer 45 nor Lev Ran's application 
transport layer 46 is equivalent to a presentation block as recited in claim 1 of the instant 
application. The "program on the system" recited in Applicant's claim 1 is not internal 
to the remote procedure call system of claim 1 per the plain meaning of the claim. Any 
other interpretation would not be consistent with the plain wording of the claim. 
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Furthermore, the Examiner has improperly cited distinct and different aspects of 
Lev Ran's system in an attempt to support the assertion that Lev Ran teaches the 
limitation a presentation block configured to present data types and Application 
Programming Interfaces (APIs) available to a program on the system . The Examiner 
cites portions of Lev Ran that are directed at Lev Ran's data encapsulation layer in regard 
to "data types", and portions of Lev Ran that are directed at Lev Ran's adaptation layer in 
regard to "APIs." Lev Ran clearly distinguishes between the data encapsulation layer and 
the adaptation layer . The Examiner's citation and arguments thus fail to support the 
assertion that the cited art teaches a presentation block as recited in claim 1 . 

In further regard to claim 1, the Examiner asserts that Lev Ran teaches an 
encoding block configured to encode representations of those data types as outgoing 
messages on an interconnect. In the Action dated April 17, 2008, in support of this 
assertion, the Examiner presents Lev Ran's data encapsulation layer 1 64 as equivalent to 
claim l's encoding block . However, as noted above, the Examiner cites portions of Lev 
Ran that are clearly directed at Lev Ran's data encapsulation layer 164 to support the 
assertion that Lev Ran teaches claim l's presentation block . The Examiner is 
improperly asserting that a single element of Lev Ran's system (data encapsulation 
layer 164) is equivalent to two different and distinct elements recited in Applicant's 
claim 1. Lev Ran's data encapsulation layer 164 cannot be equivalent to both claim l's 
presentation block and claim 1 's encoding block . 




Applicant again notes that the Examiner should consider the claim as a whole. 
Claim 1 recites a system comprising a processor and a memory comprising program 
instructions executable by the processor to implement a remote procedure call system . 
The remote procedure call system as recited in claim 1 comprises a presentation block , an 
encoding block , a protocol block , and a transport block . The Examiner's assertions in 
regard to the Lev Ran reference, in which the Examiner improperly asserts that two 
distinct elements of Lev Ran's system teach claim l's presentation block, and in addition 
improperly asserts that one distinct element of Lev Ran's system teaches both claim l's 
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presentation block and encoding block, have clearly failed to establish that the cited art 
teaches the limitations as recited in claim 1 when claim 1 is viewed as a whole. 

In further regard to claim 1, contrary to the Examiner's assertion, the cited 
art fails to teach or suggest a remote procedure call system comprising a... protocol 
block configured to frame the encodings to denote the intent of the outgoing messages. 

In the Action dated April 17, 2008, the Examiner admits that Lev Ran is silent 
with reference to a protocol block configured to frame the encodings to denote the intent 
of the outgoing messages, and asserts that Kunisetti teaches this limitation, citing 
"...SOAP Action value...", page 1 paragraph [0008], page 3 paragraph [0017], 
"...desired operation...", page 4 paragraph [0023]. 

Kunisetti teaches, in paragraph [0008]: 

Whenever a WSDL description of a particular Web service operation is 
produced, a SOAPAction value which unambiguously identifies the 
corresponding operation is also produced. This SOAPAction value is then 
placed in each HTTP SOAP message that requests that operation. . . 

In FIG. 2 and in paragraph [0022], Kunisetti teaches that the SOAPAction value 

is produced by a "WSDL creation tool 217" and placed in a WSDL Web Service 

Description 215. In paragraph [0023], Kunisetti simply states: 

In request messages sent by users, rather than using a HTTP SOAPAction 
header value that designates a WSDL service description, the 
SOAPAction header instead includes a direct reference to the 
"processElement" operation itself. 

Nowhere does Kunisetti describe any particular element (such as a "protocol 
block") that "frames" the request messages. Kunisetti does not teach or suggest in the 
citations provided by the Examiner the notion of a protocol block configured to frame the 
encodings to denote the intent of the outgoing messages. Kunisetti does not even teach 
the notion of a protocol block. Moreover, Kunisetti does not teach or suggest a protocol 
block that is one block in a remote procedure call system also comprising a presentation 
block, an encoding block, and a transport block, as is recited in claim 1 . Furthermore, 
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Kunisetti does not teach or suggest the notion of a protocol block configured to frame the 
encodings to denote the intent of the outgoing messages, instead only teaching that "[the] 
SOAP Action value is. . . placed in each HTTP SOAP message." Thus, Kunisetti clearly 
does not describe the limitation as recited in claim 1. Nor do any of the other cited 
references teach or suggest this aspect of Applicant's claim, whether considered alone or 
in combination with Kunisetti. 

In the Action dated April 17, 2008, the Examiner asserts "it would have been 
obvious... to modify the system of Lev Ran with the teaching of Kunisetti because the 
teaching of Kunisetti would improve the system of Lev Ran by using SOAP Action HTTP 
header to specify a document style operation..." However, Kunisetti does not teach or 
suggest the limitations as recited in the claim. Moreover, modifying the system of Lev 
Ran with the teaching of Kunisetti would not result in what is recited in claim 1 . The 
results would simply be Lev Ran's system in which "[the] SOAP Action value is. . . placed 
in each HTTP SOAP message." 

In further regard to claim 1, contrary to the Examiner's assertion, the cited 
art fails to teach or suggest wherein the functionality of each said block is isolated 
from the functionality of the other said blocks in the remote procedure call system so 
that program instructions for each said block can be replaced or modified without 
replacing or modifying program instructions for any of the other said blocks. 

In the Action dated April 17, 2008, the Examiner admits that Lev Ran is silent 
with reference to wherein the functionality of each said block is isolated from the 
functionality of the other said blocks in the remote procedure call system so that program 
instructions for each said block can be replaced or modified without replacing or 
modifying program instructions for any of the other said blocks, and asserts that 
Karakashian teaches this limitation. The Examienr cites "plugin component", page 1 
paragraphs [0005] - [0015], HTTP protocol adapter 102 / SMPT protocol adapter 106, 
page 2 paragraph [0021], page 2 paragraph [0022], and page 3 paragraph [0030]. 
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Applicant notes that Karakashian's disclosed Web services runtime architecture is 
clealrly and distinctly different than what is recited in claim 1 : a remote procedure call 
system comprising a presentation block, an encoding block, a protocol block and a 
transport block. 

In paragraph [0005], Karakashian discloses a system and method that utilizes a 
runtime architecture for Web services. The system includes a container driver for 
accepting an invoke request for Web services, such as from a protocol adapter. The 
container driver can perform data binding and unbinding required to process the invoke 
request, utilizing a plugin component such as a Java binding codec, SOAP codec, XML 
codec, or custom codecs. Paragraphs [0021] - [0022] again mentions Karaksshian's 
"protocol adapter" and mentions that the architecture "allows for pluggability in a 
number of places." Paragraph [0030] mentions that XML serialization and 
deserialization plugins "can be supported." 

While Karakashian does teach the notion of "plugins" for some elements in 
Karakashian's disclosed architecture and that the archtecture "allows for pluggability in a 
number of places", Karakashian clearly does not teach or suggest the limitation as recited 
in claim 1 , nor do the other cited references, alone or in combination, teach or suggest 
this limitation. In teaching the use of plugins for some elements of Karakashian's 
architecture, Karakashian simply does not teach anything close to the notion that the 
functionality of each said block is isolated from the functionality of the other said blocks 
in the system so that program instructions for each said block can be replaced or modified 
without replacing or modifying program instructions for any of the other said blocks . 
Indeed, Karakashian's statement that the archtecture "allows for pluggability in a number 
of places" indicates that Karakashian's architecture is limited as to what elements of the 
architecture are "pluggable", and moreover Karakashian does not teach or suggest that all 
of the elements in Karakashian's architecture are "pluggable". 

Thus, Karakashian clearly does not describe wherein the functionality of each said 
block is isolated from the functionality of the other said blocks in the remote procedure 
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call system so that program instructions for each said block can be replaced or modified 
without replacing or modifying program instructions for any of the other said blocks . 
Nor do any of the other cited references teach or suggest this aspect of Applicant's claim, 
whether considered alone or in combination with Karakashian. 

Furthermore, the Examiner has not stated a proper reason to combine the 
teachings of the cited art. The Examiner asserts it would have been obvious to combine 
the teachings of Lev Ran and Kunisetti with the teachings of Karakashian because the 
teachings of Karakashian would improve the system of Kunisetty and Lev Ran by 
"providing a computer program that interacts with other computer programs to provide a 
certain, usually very specific function." However, the Examiner's reason is not 
supported by any evidence of record and is thus found only in hindsight. Furthermore, 
the Examiner's reason is so broad and vague as to be essentially meaningless. One of 
ordinary skill would not have combined the teachings of Lev Ran and Kunisetti with the 
teachings of Karakashian in the manner proposed by the Examiner. Accordingly, the 
Examiner has failed to establish a prima facie case of obviousness. 

Thus, for at least the reasons presented above, the rejection of claim 1 is not 
supported by the cited art and removal thereof is respectfully requested. Similar remarks 
as those above regarding claim 1 also apply to claims 23, 34, 36 and 47. 

Regarding claim 2, since claim 2 depends from claim 1, Applicant traverses 
this rejection for at least the reasons given above in regard to claim 1. 

In further regard to claim 2, contrary to the Examiner's assertion, the cited 
art fails to teach or suggest wherein the presentation block is further configured to 
provide the data types from the incoming messages to the program on the system. The 
Examiner cites Lev Ran, col. 56, lines 16-25 in support of this assertion, and appears to 
equate "...response messages..." with "data types from the incoming messages." The 
context of that snipped quote from Lev Ran is: 
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Remote services are activated by bidirectionally transferring remote 
procedure call (RPC) messages between a client application transport 
layer ("RPC client") on one VFN gateway and a server application 
transport layer ("RPC server") on a second remote VFN gateway. 
Preferably, the application transport layer functions asymmetrically, 
whereby the RPC client sends RPC request messages to the RPC server, 
and the RPC server responds by sending RPC response messages to the 
RPC client. 

The above citation does not teach or suggest anything like a presentation block 
[that] is... configured to provide the data types from... incoming messages to [a] 
program on the system. In the citation, the RPC response messages are sent from an 
RPC server to an RPC client in response to RPC request messages sent by the RPC client 
to the RPC server. An RPC client is a "client application transport layer... on one VFN 
gateway." Lev Ran further describes the client application transport layer (RPC client) 
beginning at col. 61, line 20. Note that the RPC client is clearly disclosed as a 
component of Lev Ran's VFN system, and not as a program separate from the system. 
The RPC client and RPC server components exchange RPC request and RPC response 
messages internal to Lev Ran's VFN system. Neither one of the components is described 
as providing the data types from incoming messages to a program on the system. 

In the Action dated May 15, 2007, in response to the above argument, the 

Examiner again asserts "the 'java object/object class or type' passed in an RPC 
request/response describes the data type passed between remote systems as the instant 
application discloses." Applicant refers the Examiner to the Applicant's responses to this 
argument in regards to claim 1. Furthermore, Applicant again notes that the RPC 
response messages are sent from an RPC server to an RPC client in response to 
RPC request messages sent by the RPC client to the RPC server. The RPC client 
and RPC servers are clearly disclosed as components of Lev Ran's VFN system, and 
neither is disclosed as "a program separate from the system". The RPC client and 
RPC server components exchange RPC request and RPC response messages 
internal to Lev Ran's VFN system . Neither one of the components is described as 
providing the data types from incoming messages to a program on the system . 
Furthermore, in claim 2, it is clearly recited that the receiving of messages from a 
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"remote system" is handled by the transport block of the remote procedure call system, 
and not by the presentation block of the remote procedure call system. The presentation 
block is instead configured to provide the data types from the incoming messages to the 
program on the system . Furthermore, the "program on the system" in claim 2 is clearly 
and distinctly a different entity than the "remote system" from which incoming messages 
are received by the transport block . 

In further regard to claim 2, contrary to the Examiner's assertion, the cited 
art fails to disclose wherein the protocol block is further configured to determine the 
intent of the encoded and protocol framed incoming messages. In the Action dated 
April 17, 2008, the Examiner asserts that Kunisetti teaches this limitation, citing 
"...SOAP Action value...", page 1 paragraph [0008], page 3 paragraph [0017], 
"...desired operation...", page 4 paragraph [0023]. 

In FIG. 2 and in paragraph [0022], Kunisetti teaches that the SOAP Action value 

is produced by a "WSDL creation tool 217" and placed in a WSDL Web Service 

Description 215. In paragraph [0023], Kunisetti states: 

In request messages sent by users, rather than using a HTTP SOAP Action 
header value that designates a WSDL service description, the 
SOAP Action header instead includes a direct reference to the 
"processElement" operation itself. As illustrated in FIG. 2, the Web server 
207 evaluates the SOAP Action header value 230 extracted from the SOAP 
wrapper of the incoming request message, detects the presence of the 
string literal "um:oracle" in the SOAP Action header value that indicates 
that the remainder of the string value contains a direct identification of the 
"processElement" operation, and then directly invokes that operation 
without the need to retrieve, parse or evaluate a WSDL service 
description. 

Kunisetti only broadly states that the "Web server 207" evaluates the 
SOAP Action header. Nowhere does Kunisetti describe any particular element (such as a 
"protocol block") that determines the intent of encoded and protocol framed incoming 
messages. Kunisetti does not teach or suggest in the citations provided by the Examiner 
the notion of a protocol block configured to determine the intent of the encoded and 
protocol framed incoming messages. Kunisetti does not even teach the notion of a 
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protocol block. Moreover, Kunisetti does not teach or suggest a protocol block that is 
one block in a remote procedure call system also comprising a presentation block, an 
encoding block, and a transport block, as is recited in claim 1 . 

In addition, in regard to claim 1, the Examiner asserts Kunisetti teaches a protocol 
block configured to frame the encodings to denote the intent of the outgoing messages. In 
claim 2, the same protocol block is described as being further configured to determine the 
intent of the encoded and protocol framed incoming messages, and the Examiner relies 
on the same portions of Kunisetti to teach this reference. However, it is clear from 
Kunisetti's Figure 2 and description thereof (e.g., the cited portion of paragraph [0023]) 
that Kunisetti does not teach or suggest one element (e.g., a protocol block) that is both 
configured to frame outgoing messages to denote the intent of the outgoing messages and 
to determine the intent of encoded and protocol framed incoming messages according to 
Kunisetti's disclosed system. 

Thus, Kunisetti clearly does not describe the limitation as recited in claim 2. Nor 
do any of the other cited references teach or suggest this aspect of Applicant's claim, 
whether considered alone or in combination with Kunisetti. 

Thus, for at least the reasons presented above, the rejection of claim 2 is not 
supported by the cited art and removal thereof is respectfully requested. Similar remarks 
as those above regarding claim 2 also apply to claims 26, 35, 39 and 50. 

Regarding claim 3, since claim 3 depends from claim 2, Applicant traverses 
this rejection for at least the reasons given above in regard to claim 2. 

In further regard to claim 3, contrary to the Examiner's assertion, the cited 
art alone or in combination fails to teach or suggest to determine the intent of the 
encoded and protocol framed incoming messages, the protocol block is further 
configured to determine if the incoming messages are reqeuest messages or response 
messages. 
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In the Action dated April 17, 2008, the Examiner asserts that Kunisetti teaches 

this limitation, citing "...determine...", page 1 paragraph [0008]. The only place that 

"determine" is used in that paragraph is in: 

When the HTTP server that provides the Web service receives the HTTP 
request, the SOAP Action header is evaluated to determine whether the 
first part is present and, if it is, the second part is used to directly identify 
and call a specified operation. 

First, this citation teaches that the SOAPAction header is evaluated to determine 
whether the first part is present , and not to determine if the HTTP request being evaluated 
is a request message or a response message. Second, what is being evaluated is the 
SOAPAction header of an HTTP request . The HTTP request is clearly not being 
evaluated to determine if it is a request or a response, as an HTTP request is clearly 
alreadly known to be a request. 

Thus, Kunisetti clearly does not describe the limitation as recited in claim 3. Nor 
do any of the other cited references teach or suggest this aspect of Applicant's claim, 
whether considered alone or in combination with Kunisetti. 

Thus, for at least the reasons presented above, the rejection of claim 3 is not 
supported by the cited art and removal thereof is respectfully requested. 

The Examiner rejected claim 4 under 35 U.S.C. § 103(a) as being unpatentable 
over Lev Ran in view of Kunisetty and in further view of Karakashian and further in view 
of U.S. Publication 2003/0204586 to Schnetzler. However, since the rejections have 
been shown to be unsupported for the independent claims, a further discussion of this 
rejection is not necessary at this time. 

Applicant also asserts that the rejections of numerous ones of the dependent 
claims are further unsupported by the cited art. However, since the rejections have been 
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shown to be unsupported for the independent claims, a further discussion of the 
dependent claims is not necessary at this time. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and notice to that 
effect is respectfully requested. 



If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
64301/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Applicant 
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